home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20031118-20041115 / 000406_slash_dev_slas…_2000@yahoo.com_Fri Sep 24 17:37:48 2004.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Path: newsmaster.cc.columbia.edu!newsfeed1.nycmny01.us.to.verio.net!newsfeed1.stngva01.us.to.verio.net!newspeer1.stngva01.us.to.verio.net!verio!news.tele.dk!news.tele.dk!small.news.tele.dk!news.glorb.com!postnews1.google.com!k26g2000oda.googlegroups.com!not-for-mail
  2. From: "Mark Sapiro" <slash_dev_slash_null_2000@yahoo.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: Return codes and If statments
  5. Date: 24 Sep 2004 14:33:57 -0700
  6. Organization: http://groups.google.com
  7. Lines: 142
  8. Message-ID: <1096061637.174541.255970@k26g2000oda.googlegroups.com>
  9. References: <3f9c05b0.0409211252.5aa51cb1@posting.google.com>
  10.    <slrncl18i5.56s.fdc@sesame.cc.columbia.edu>
  11.    <1095827419.338981.28270@k26g2000oda.googlegroups.com>
  12.    <3f9c05b0.0409220853.25e5bd46@posting.google.com>
  13.    <slrncl3dp2.ftp.fdc@sesame.cc.columbia.edu>
  14. NNTP-Posting-Host: 209.182.169.133
  15. Mime-Version: 1.0
  16. Content-Type: text/plain; charset="iso-8859-1"
  17. X-Trace: posting.google.com 1096061637 23677 127.0.0.1 (24 Sep 2004 21:33:57 GMT)
  18. X-Complaints-To: groups-abuse@google.com
  19. NNTP-Posting-Date: Fri, 24 Sep 2004 21:33:57 +0000 (UTC)
  20. In-Reply-To: <slrncl3dp2.ftp.fdc@sesame.cc.columbia.edu>
  21. User-Agent: G2/0.2
  22. Complaints-To: groups-abuse@google.com
  23. Injection-Info: k26g2000oda.googlegroups.com; posting-host=209.182.169.133;
  24.    posting-account=iQNWIg0AAAAD2fStXNC9nwGlPdSqjWrI
  25. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15183
  26.  
  27. Frank da Cruz wrote:
  28. > On 2004-09-22, Peter V. <dm_v_2000@yahoo.com> wrote:
  29. > :   thank you both for your advice.  I am sticking to recommended
  30. format
  31. > : Number 2, and that seems to have done the trick.
  32. > :
  33. > I realize it might be a big counterintuitive for C programmers, but
  34. it
  35. > should be recalled that Kermit differs from C not only in being
  36. interpretive
  37. > rather than compiled, but also it's an interactive command language,
  38. and
  39. > therefore necessarily line-oriented: each command is one line.  Thus
  40. the
  41. > true format of a compound IF-ELSE statement is:
  42. >
  43. >   if <condition> { command, command, ... } ELSE { command, command,
  44. ... }
  45. >
  46. > Prior to C-Kermit 7.0, if you wanted to break such a statement onto
  47. multiple
  48. > lines, you had to use line continuation:
  49. >
  50. >   if <condition> { -
  51. >       command, -
  52. >       command, -
  53. >       ... -
  54. >   } ELSE {
  55. >       command, -
  56. >       command, -
  57. >       ... -
  58. >   }
  59. >
  60. > Version 7.0 added several tricks to the parser to give more natural
  61. > syntax: (a) If a line ENDS with "{" (ignoring whitespace) it is
  62. continued
  63. > and begins a block; (b) if a line BEGINS with "}" (ignoring
  64. whitespace) it
  65. > ends a block; (c) if a block is active, the end of each line implies
  66. a
  67. > comma (which is used to separate statements within blocks).  Once a
  68. block
  69. > is opened at top level, these tricks are used until the block is
  70. closed,
  71. > and naturally, they persist through any level of nesting.  This
  72. explains
  73. > why a construction like:
  74. >
  75. >   IF <condition> {
  76. >      command
  77. >      command
  78. >   }
  79. >
  80. > works, but:
  81. >
  82. >   IF <condition>
  83. >   {
  84. >      command
  85. >      command
  86. >   }
  87. >
  88. > doesn't.  The first line is an incomplete command with no indication
  89. of
  90. > continuation.  The documentation:
  91. >
  92. >   http://www.columbia.edu/kermit/ckermit70.html#x7.20
  93. >
  94. > does not list the latter form as a possibility.
  95.  
  96. That is true, but that was not my point in my prior post in this
  97. thread. My point is that ever since 8.0.206. The forms of examples 3
  98. and 4 in the referenced documentation do not always produce the same
  99. results as the forms of examples 1 and 2.
  100.  
  101. In particular,  consider example 2 - the preferred form
  102.  
  103. IF condition {
  104. command1
  105. command2
  106. } ELSE {
  107. command3
  108. command4
  109. }
  110.  
  111. vs. Example 3 (same as 1 and 2):
  112.  
  113. IF condition {
  114. command1
  115. command2
  116. }
  117. ELSE { command3, command4 }
  118.  
  119. and Example 4 (same as 1-3):
  120.  
  121. IF condition {
  122. command1
  123. command2
  124. }
  125. ELSE {
  126. command3
  127. command4
  128. }
  129.  
  130. As far as I can tell, example 2 always works as expected, but in the
  131. case where condition is False and command3 and or command 4 contains a
  132. Macro reference, the macro reference will not be expanded in example 3
  133. and 4 as it is in example 2.
  134.  
  135. This is illustrated by the following:
  136.  
  137. # Example 2 (same as Example 1):
  138.  
  139. IF false {
  140. .theday := \v(day)
  141. show macro theday
  142. } ELSE {
  143. .thedate := \v(date)
  144. show macro thedate
  145. }
  146.  
  147. # Example 3 (same as 1 and 2):
  148.  
  149. IF false {
  150. .theday := \v(day)
  151. show macro theday
  152. }
  153. ELSE { .thedate := \v(date), show macro thedate }
  154.  
  155. If this is run today, example 2 will output
  156.  
  157. thedate = 24 Sep 2004
  158.  
  159. but example 3 will output
  160.  
  161. thedate = \v(date)
  162.  
  163. This behavior was introduced by changes in the way immediate macro's
  164. are handled in ckuusr.c, 23 Aug 2002.
  165.  
  166. These changes were intended to solve a problem that might more properly
  167. have been addressed by escapes in the command.
  168.